I. Field of the Invention
The present invention provides a method for generating computer software for microprocessors used in embedded systems.
II. Description of Related Art
The use of microprocessors in embedded, i.e. dedicated, systems has become increasingly prevalent as the cost of such microprocessors and their associated components decreases coupled with an increase of computing capability of such microprocessors. For example, such microprocessors are frequently used in the fuel management systems for automotive vehicles, as well as many other applications.
The exact configuration of embedded systems will vary not only between different systems involving different applications, but also between the different types of microprocessors employed in such systems. However, despite the large variation not only in the types of different systems as well as the different types of microprocessors, all embedded systems share certain characteristics.
More specifically, all microprocessors in embedded systems include a basic input/output system (BIOS) having one or more input/output channels. Each channel is capable of sending and/or receiving data from an exterior device using basic input/output protocol. For example, assuming that the embedded system consists of a fuel management system for an automotive engine, the BIOS for the microprocessor may receive data from a mass airflow sensor, temperature sensor and the like. Furthermore, this data may be in any of several protocols, e.g. pulse width modulation, serial data, parallel data, etc. Typically, each channel of the microprocessor is dedicated to one external device and typically the microprocessor includes multiple channels to control and/or receive input signals from multiple external devices.
The software for embedded microprocessor systems also includes an application layer which processes the input/output signals from the BIOS. For example, assuming that the embedded system consists of a fuel management system for an internal combustion engine, the application layer would receive input signals from the BIOS representative of, for example, the output signals from a mass airflow sensor, temperature sensor and the like. The application layer would then process these input/output signals in the desired fashion to achieve the desired end function, i.e. the fuel management control for the engine.
For example, the application layer may receive input signals from the BIOS representative of the output from a mass airflow sensor, temperature sensor, as well as other sensors. The operating system, utilizing the input signals from the BIOS, would then calculate a desired throttle position to achieve a desired result such as fuel economy, lower emissions, better engine performance, etc. Having determined that value for the throttle position, the application layer would then, through a channel in the BIOS, generate output signals to an electronically controlled throttle in order to move the throttle to the desired position.
Typically in an embedded system such as a fuel management system for an internal combustion engine, the application layer includes a plurality of different code modules wherein each code module processes different types of signals or inputs depending upon the type of external sensors or devices controlled by the microprocessor as well as the protocol used by those sensors or control devices.
Microprocessors of the type used in embedded systems are typically single tasking microprocessors, i.e. the microprocessor can execute a single series of software instructions at a given time. Consequently, in order to schedule the execution of the various program modules in the application layer, the embedded systems include an operating system (OS) which schedules the execution of the various modules in the application layer at preset time intervals.
For example, in a typical embedded system of the type used for the fuel management control for an engine having a temperature sensor, a mass airflow sensor and an electronic throttle, the operating system may, for example, control the execution of the various code modules within the application layer to process a signal from the mass airflow sensor every 50 milliseconds, process the temperature signal from the temperature sensor every 1000 milliseconds, and to process the output to the electronic throttle control every 10 milliseconds. Typically, the OS controls the scheduling of the execution of the modules in the application layer by way of software interrupts. Additionally, however, the operating system may schedule the execution of program modules in the application layer in response to hardware interrupts.
Consequently, in order to fully program a microprocessor in an inventive system, it is necessary to coordinate not only the software programming between the BIOS and the application layer, but also between the operating system and the application layer in order to achieve the desired programming for the microprocessor.
In order to facilitate the generation of programming for microprocessors in embedded systems, there have been a number of previously known software tools to facilitate the generation of software for the microprocessors in such embedded systems. Typically, the software utilizes C programming although other programming languages may also be used.
One previously known software tool to facilitate the programming of microprocessors in such systems is Real-Time Architect (RTA) by LiveDevices. The RTA software tool can be used to automatically generate the operating system kernel files for specific target microprocessors. However, the software generated by RTA must be manually inputted by the programmer in order to properly connect the operating system with the application layer. Furthermore, the programmer must manually ensure that no conflicts exist with the BIOS or debugger settings for the microprocessor.
A still further software tool for generating software is Ascet-SD from ETAS. The Ascet software tool can be used to generate software in the C language for both the operating system as well as the application layer. The Ascet-SD software tool also has Ercosek integrated within it which generates the operating system program code. However, the Ascet-SD software tool does not integrate the application layer with the BIOS. Consequently, such integration between the application layer and the BIOS must be done manually.
A still further software tool is known as TargetLink from dSPACE. The TargetLink software tool utilizes a graphical interface to automatically generate software in the C programming language for the application layer only. TargetLink is incapable of generating software code for either the OS or the BIOS and, as such, integration of the application layer with both the OS and the BIOS must be done by hand.
MakeApp by IAR also forms a software tool for automatically generating software for microprocessors in embedded systems. However, the MakeApp system only generates software in the C programming language for the BIOS. The BIOS code must then be manually integrated by the programmer with the application layer and the operating system.
Real-Time Workshop (RTW) by Mathworks also forms a software tool for generating computer software for microprocessors in embedded systems. While RTW provides for automatic code generation for microprocessors, it is limited to two families of microprocessors and cannot be used with other types of microprocessors. Such other microprocessors, of course, may be necessary for a particular application where, for example, the number of channels supported by the BIOS for the microprocessors supported by RTW are insufficient for that particular application.
Consequently, all of the previously known software tools for generating software for microprocessors used in embedded systems are necessarily limited not only by the type of microprocessor that is supported by the software tool, but in other cases which require hand computer software coding. Such hand coding is not only type consuming, and therefore expensive, but is also prone to error. Such errors further lengthen the time necessary to test and debug the overall system.